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ABSTRACT 



A distributed vehicle information processing and vehicle 
control system has at least one first system part on board the 
vehicle side and at least a second system part, each for 
carrying out one or more vehicle-related application 
functions, with the system parts communicating with one 
another via an associated data transmission network. The 
systems parts have a component-based construction com- 
posed of different components, which communicate with 
one another in order to carry out different functions. Each 
component has a function-calling interface, via which the 
function carried out by the component can be called up by 
other components, in this system part or in another system 
part, and a configuration interface via which its configura- 
tion can be defined and varied. A configuration manager 
unit, provided for this purpose, configures the components 
via this interface depending on what other components are 
present in the system. 

4 Claims, 7 Drawing Sheets 
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DISTRIBUTED VEHICLE INFORMATION 
PROCESSING AND VEHICLE CONTROL 
SYSTEM 



BACKGROUND AND SUMMARY OF THE 
INVENTION 

This application claims the priority of German patent 
document 199 09 157.9, filed Mar. 2, 1999, the disclosure of 
which is expressly incorporated by reference herein. 10 

The invention relates to a distributed vehicle information 
processing and vehicle control system, having at least two 
system parts as network nodes which communicate via a 
data transmission network, and at least one of which is 
arranged on the vehicle side. 15 

Overall, such systems are used for carrying out vehicle- 
related applications of widely varying types, for example in 
conjunction with user interfaces, internal and external 
communication, application support and with the actual ^ 
applications and services themselves. The latter includes, for 
example, actuation of vehicle units, evaluation of vehicle 
sensor information and general services such as navigation, 
diagnosis, anti-theft devices and data interchange with 
remote network nodes, for example via the Internet. ^ 

Modern vehicle systems are distinguished by a data 
processing element that is becoming ever larger; that is to 
say telematics applications are becoming increasingly 
important. For example, breakdown services and dynamic 
navigation services as well as Internet-based applications 3Q 
demand the implementation of distributed systems, in which 
the vehicle is no longer regarded as an isolated individual 
system, but as an active node in a distributed data commu- 
nications system, preferably with a worldwide range. Sys- 
tem applications implemented aboard the vehicle will in this 35 
case in general carry out not only client functions but also 
server functions. 

The layering of functionalities that are required for a 
vehicle system has already been proposed for a vehicle 
communications system disclosed in German Patent Docu- 40 
ment DE 196 25 002 Al, which uses adaptive application 
control, and allows a certain amount of variability in the 
assignment of the applications to various interfaces and 
appliance units on the vehicle side. 

In the field of general data processing, a component-based 45 
system design has recently been proposed as an alternative 
to central system architectures. See, for example, the Journal 
article D. Kiely, "Are Components — The Future of 
Software?", IEEE Computer Magazine, page 10, February 
1998. In this case, the function to be provided by the overall 50 
system is broken down into individual functional units 
("components"), which then provide the overall desired 
function by suitable linking and communication with one 
another. Such breakdown into components on the one hand 
simplifies their reuse and the design of complex systems 55 
from these components, and on the other hand simplifies the 
production of robust components themselves (since they 
need be equipped with only a limited, clear functional 
scope). The components are characterized by their external 
identical architecture, which makes it possible to link them 60 
to one another in a simple manner, such that the function 
provided by a particular component may initially be viewed 
independently of this architecture. 

The explosive growth in the Internet and the Worldwide 
Web has led to distributed systems becoming increasingly 65 
important. To simplify the implementation of such systems, 
and to allow component-based systems to be provided, an 
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increasing number of distributed object models have been 
established. The system developers are also making ever 
greater use of Internet-oriented solutions for these object 
models and are implementing them, for example, using Java 
RMI or "Java Beans". See the corresponding Internet infor- 
mation from Sun Microsystems with DCOM from 
Microsoft; see also, the publications T, Albertson, "Best 
Practices in Distributed Object Application Development: 
RMI, CORBA and DCOM, February 1998, Internet page 
"http://developer.com/news/techfocus/0223 98_distl.htm" 
and P. E. Chung et ah, "DCOM and CORBA Side by Side, 
Step by Step, and Layer by Layer, September 1997, Internet 
page "http://www.cs.wustl.edu/-schmitt/submit/ 
Paper.html", or, on the basis of CORBA, see also A. Vogel, 
K. Duddy, "Java Programming with CORBA", John Wiley 
& Sons, 1997. 

As is evident from the cited literature, the trend towards 
object-oriented component models can be explained by the 
following advantages: first, by the capability for reuse of 
existing algorithms and software, and for "rapid prototyp- 
ing" of applications by "plug-and-play" interaction of the 
components; second, mutually independent development 
and implementation of components; third efficient code 
maintenance including the systematic distribution of 
updates; and fourth "lightweight" and "thin clients" 
implementations, which communicate with infrastructure - 
based systems, which can be localized there at various 
points. 

One of the characteristic features of such components is 
that they follow a standard architecture specification, which 
makes it easier to join them together to form an overall 
system. In this case, this architecture in principle has nothing 
to do with the actual function of the component. In fact, it 
defines how the components interact with one another, but 
not how they "converse". This characterization is indepen- 
dent of whether the specific component is in the form of 
software or hardware. 

The trend towards component models is evident in the 
increasing importance of technologies which support dis- 
tributed component systems, such as "Java Remote Method 
Invocation (RMI)** as the basis for the JavaBeans compo- 
nents "Common Object Request Broker Architecture 
(CORBA)*' and "Distributed Component Object Model 
(DCOM)" from Microsoft for implementation of ActiveX. 
All these models use the client/server approach. 

In the past, when vehicles have been delivered to the 
customer at the end of production, their functionality in 
terms of services that can be carried out has been relatively 
greatly fixed. In the future, however, more and more services 
will be used in vehicles, in the same way that they are also 
being used in the office and business worlds, even though 
they still scarcely exist at all at the moment when the vehicle 
is manufactured. In future, the customer will therefore wish 
to be able to reequip the vehicle with corresponding new 
services, for the life of the vehicle. If the reequipment is 
done by additionally downloading software into the vehicle, 
then the memory space required for this purpose in the 
vehicle will at some time no longer be adequate. On the 
other hand, reequipment additional hardware is compara- 
tively costly and susceptible to faults, and in most cases 
involves the vehicle being left in a workshop. 

There is therefore a requirement for systems which can 
relatively easily be reequipped with additional functions 
which are provided, for example, as software modules, so 
that no hardware modification is required. Furthermore, it is 
desirable to be able to match the system optimally to 
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changing requirements and conditions by dynamic 
movement, preferably of software modules, to or from the 
system part on the vehicle side, for the life of the vehicle. 
This applies, for example, to changing conditions for wire- 
less communication. If only narrowband communication is 5 
available, as little communication as possible should be 
carried out and as much of the necessary software as 
possible should be accommodated in the vehicle. On the 
other hand, if a communications link with a high transmis- 
sion capacity is available, certain operating software can 3Q 
more advantageously be accommodated in a system part 
outside the vehicle, in order to allow the generally greater 
computation capacities there to be utilized. 

One object of the present invention is to provide a vehicle 
information processing and vehicle control system of the ^ 
type mentioned initially, whose structure for carrying out 
various vehicle- related applications is designed compara- 
tively flexibly, so that reequipping with further functions is 
possible at relatively low cost. Also, the precondition is 
provided to allow the required applications to be carried out ^ 
such that they are distributed variably, dynamically and 
flexibly between the system parts, and such that the vehicle 
can be integrated as an active network node in a data 
network which may be worldwide. 

These and other objects and advantages are achieved by 25 
the distributed vehicle information processing and vehicle 
control system according to the invention, whose system 
parts have a component-based construction, being composed 
of different components which communicate with one 
another in order to carry out the various desired application 3Q 
functions. Each of these components, which are defined in 
this way and are preferably in the form of software on the 
one hand, has a function-calling interface via which the 
function carried out by the component can be called up by 
all the active nodes in the network, and a configuration 35 
interface, via which its configuration can be defined. Thus, 
it can be varied, by means of a configuration manager unit 
provided for this purpose. 

To this end, the configuration manager unit receives 
knowledge about the components that are present in the 40 
system, and configures the respective component, via its 
configuration interface, depending on what other compo- 
nents are present. In consequence, this configuration man- 
ager unit allows a component which has been newly fitted in 
a system part (irrespective of whether this is by reequipment 45 
of the system with the same system part or by movement 
from another system part) to be "configured** such that it can 
communicate optimally with the other components that are 
present. 

Matching of the new components to the relevant system 50 
part may possibly also involve a modification of the con- 
figuration of one or more of those components which were 
already present. This design allows the vehicle- related sys- 
tem to be equipped with a general data processing platform, 
which allows flexible reloading of further executable 55 
vehicle-related applications at any time during the life of the 
vehicle, while allowing optimized-cost reaction by service 
implementations to variable external conditions. 

In one embodiment of the invention, a component loader 
is provided for the respective system part (also referred to as 60 
a "bathtub" in general computer processing), which accom- 
modates the respective components. The latter communicate 
via the component loader with an operating system in the 
system part to which, on the other hand, various external 
appliance units are coupled, depending on the system part. 65 

In another embodiment of the invention, a function -based 
hierarchy of the components is provided in vehicle- 
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component- related components or "interface" components, 
which are closely based on the existing hardware, vehicle 
appliance units and, for example, provide access to hardware 
interfaces for communications appliances or the display and 
control appliances of a user interface. Aggregation compo- 
nents offer services which aggregate raw information from 
the vehicle-component-related components, and in higher- 
level application components represent the actual services 
and have access not only to the aggregation components but 
also to an intermediate layer and to the vehicle -component- 
related components and user-interface components. 

According to another feature of the invention, means are 
provided for dynamically moving one or more of the com- 
ponents between the involved system parts during the sys- 
tem life, and thus, in particular, at any desired times through- 
out the entire life of the vehicle. These means for moving 
components make use of the fact that the components are 
provided with a configuration interface and are "config- 
urable" via this interface. Thus, they can be varied to match 
a new component environment of a different system part. In 
consequence, a respective component can, for example, be 
placed in one system part for certain times and in another 
system part for other times, depending on the changing 
external conditions, such as the available transmission 
capacity of the network communication path. Those com- 
ponents which are not closely related to vehicle -side hard- 
ware appliance units are particularly suitable for such move- 
ment. 

Finally, according to another feature of the invention, 
communication between application-related components is 
direct, and thus the components must know the interfaces of 
those components which they use. Alternatively, communi- 
cation takes place via a respective, jointly used data- 
maintenance component, to which the application compo- 
nents involved write new information; and information that 
has newly been written there can be read by other involved 
components. In this case, the application components do not 
need to know the interfaces of the other components, but it 
is necessary to agree what contents are written to the 
data-maintenance component. 

Other objects, advantages and novel features of the 
present invention will become apparent from the following 
detailed description of the invention when considered in 
conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a schematic illustration of a distributed 
vehicle information processing and vehicle control system 
having system parts on board and external to the vehicle, 
which are networked with one another; 

FIG. 2 shows a schematic block diagram of the environ- 
ment of a port manager component in the system part on the 
vehicle side in FIG, 1; 

FIG. 3 shows a schematic block diagram of the environ- 
ment of a location manager component in the system shown 
in FIG. 1; 

FIG. 4 shows a schematic block diagram of the environ- 
ment of a presentation manger component in the system 
shown in FIG. 1; 

FIG. 5 shows a schematic block diagram of the basic, 
component-based architecture of the system shown in FIG. 
l; 

FIG. 6 shows a schematic block diagram of the function- 
based, hierarchical breakdown of the components in the 
system shown in FIG. 1; 
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FIG. 7 shows a schematic block diagram which illustrates 
the dynamic movement of a component between system 
parts in FIG. 1; 

FIGS. Ha and Hb show schematic block diagrams which 
illustrate component movement, using the example of a 5 
voice control application; 

FIG. 9 shows a schematic block diagram of a navigation 
subsystem of the system shown in FIG. 1, based on a service 
interface; 

10 

FIG. 10 is a schematic block diagram which shows a 
service interaction in the system shown in FIG. 1 via a 
data-maintenance component; and 

FIG. 11 shows a schematic block diagram to illustrate the 
calling of a component method. 15 

DETAILED DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows, schematically, a distributed vehicle infor- 
mation processing and vehicle control system which com- 
prises a plurality of physically separated system parts la, 2a, 20 
3a, which form active network nodes in a data transmission 
network 4, such as the Internet, and communicate with one 
another via this network. A first system part la is located in 
the vehicle 1 itself, which represents a "mobile host" in the 
network 4. A second, stationary system part la is located in 25 
a service provider 2, while a third system part 3a is located 
in a high-performance service center 3. Other vehicles may 
form active network nodes in the same way, which can 
access services from the service provider 2 and from the 
high-performance service center 3. (Although not shown, 30 
there may in each case also be a plurality of the two 
last-mentioned service providers in the data network 4.) 

The service providers 2, 3, which are external to the 
vehicle, are normally used primarily to carry out such ^ 
services for the vehicle 1 as require a relatively high 
computation capacity that is not per se available in the 
vehicle 1. This may include, for example, complex naviga- 
tion services such as route finding based on the traffic 
situation. Similar to the stationary service providers 2, 3, the 
vehicle 1 has a network identity, by means of which it is 
known in the network 4. The function blocks of the three 
illustrated network nodes 1, 2, 3 schematically indicate that 
the system part la, 2a, 3a respectively implemented there 
has a component-based design, which will be described in 45 
more detail below. 

For the present application of vehicle systems, it appears, 
from the three conventional technologies mentioned above 
which support distributed component systems, namely RMI, 
CORBA and DCOM, that the Java-RMI technology is so 
particularly suitable for this purpose, since this is not depen- 
dent on the platform and can be handled with relatively little 
complexity. 

The components which are used to form the system parts 
1, 2, 3, and thus the system overall, each include two 55 
interfaces: a function-calling (or remote) interface, via 
which the actual function of the relevant component (that is 
to say its service) can be called by another component in the 
same system part or elsewhere by a remote network node, 
and a configuration interface, which is used for variable go 
configuration of the component, to match the situation. The 
configuration interface allows the component to be "config- 
ured" variably in different system environments, and exist- 
ing components can be made aware of the newly positioned 
component via this interface. 55 

This allows a component to be easily fitted and moved 
(even after the system generation) for the system life, and 
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even if the system boundary conditions change. In this case, 
the newly fitted system components, and system compo- 
nents (which may already be present in some circumstances) 
would have to be matched to one another. This may mean, 
for example, that the addresses of the components would 
have to be made known to one another, for which purpose 
the components offer their own "home page" via which the 
necessary modifications can be carried out. A specific con- 
figuration manager unit is provided in this case in order to 
carry out this configuration task. This unit knows which 
components are currently in the system and, via the con- 
figuration interface, has access to the individual 
components, in order to modify their configuration. 

The system part 2a of the service provider 2 primarily 
contains application components for carrying out services 
with a vehicle -related functionality, while the system part 3a 
of the high-performance service center 3 primarily contains 
application support components, which require high- 
performance computation capacities. Apart from application 
components which represent the actual service applications, 
the on board vehicle system part la primarily also has 
components "close to the equipment", which are used to 
control hardware appliance units installed in the vehicle 1, 
such as a presentation manager component 19, which 
accesses a visual display 24 and a loudspeaker 26. 

In addition, communication manager components are 
used to handle data communication procedures between the 
system parts la, 2a, 3a via the network 4. The entity formed 
by the components of the respective system part la 2a, 3a 
has an associated component loader ("bathtub") or compo- 
nent server lb, 2b, 3b. One suitable example of such a 
component loader is the ChaiServer from Hewlett-Packard, 
which is implemented in the Java programming language 
and supports the loading of the components as well as the 
routing of method calls to the appropriate components; for 
further details, see the Company information document 
Hewlett-Packard "HP ChaiServer: An Overview" on the 
Internet page "http://www.chai.hp.com/emso/pdf/ 
chaiserverwp.pdf" and "HP Application Server" on the 
Internet page "http://www.hpconnect.com/embedded/vm/ 
sweb.htm". 

FIGS. 2 to 4 show three examples of components of the 
vehicle information processing and vehicle control system. 
FIG. 2 shows a port manager component 5 in its system 
environment, for example within the system part located in 
the vehicle 1. The port manager component 5 is part of a 
group of interface components which support hardware and 
carry out functions which are closely linked to hardware 
appliance units on the vehicle side, for example driver 
functions. The port manager component 5 allows access to 
a serial interface 6 of the machine (in this case the vehicle 
1, on which it runs). In this case, the access methods are 
provided such that any authorized remote component can 
access it. The port manager component 5 to this end knows 
the system interfaces and, inter alia, controls the assignment 
of the interfaces and of the connected appliances. It is also 
responsible for controlling concurrent calls by other com- 
ponents to the ports. 

Via its remote interface Sa, the port manager component 
5 allows access to the system interfaces from any given point 
in the network, for example from two explicitly shown 
applications la, lb. The configuration interface Sa of the 
port manager component 5 is also shown schematically. The 
port manager component 5 has no information about the 
semantic content of the information which is called or 
written via it. In the chosen Java implementation, it is thus 
possible for the Java Virtual Machine (JVM) 8 to use 
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additionally formed classes 9, that is to say "port classes" to although there are no hierarchies between the individual 

allow physical access to the serial interface 6. components K lf . . . K>, at this level. 

The function of the location manager component or Tn e communication between the system objects is based 

position manager component 10, which is shown embedded 011 conventional procedures, such as "remote procedure call" 

in the architectural system environment in FIG. 3, is to 5 (RPQ and its Java version, the "remote method invocation" 

collect position information and then to offer this informa- ( R ^0- Me thods relating to a component which are intended 

tion in aggregated form as a position information service. to , bc f ^ bv anoth £ component are described in an 

Possible information sources are, for example, a GPS ^ .^^^ ^ lhe ^^ace description 

, . t 4A • i_ language" (IDL) in CORB A. The required "stubs" are then 

receiver 11 and integrated navigation sensors 12, 13, such as b C1 , , ^ . . ™ 

j u , i *■ t tu i «• m generated from this file, and are linked to a component. The 

a compass and wheel revolution counter. The location man- 10 f t . c , / JJ/TinT v . , - , r , . 

*u* j • . * * _r uniform resource locator (URL) is used for addressing the 

age r component 10 to this end accesses appropriate interface t , . , . . . , t >, 4 .. . . r 

& r . , i * j u method, which is used to address that machine on which the 

components, such as the port manager 5 mentioned above ' , . , ,. , - 

/ nxKT r . 5 . . . . c . addressed component is running and on which, furthermore, 

and a CAN manager component 14 which, for its part, \ , & , . , ' , ... 

PAX , . . _r J . n , u/ 4 . \ the component itself and the desired method, with an 

accesses a CAN interface 16 via the J VM/operating system ; , . c , TmT . . 

l a er 15 15 ar gument, can be specified. URL addressing results in posi- 
tion transparency, that is to say positioning independent of 

A movement arrow 17 shows a movement option, in the componcntSf s i nce the machine address is resolved 

which the location manager component 10 need not neces- independently of the client entity, for example via a "domain 

sarily run on the same machine (for example the vehicle 1) name service" (DNS) 

as the interface components 5, 14 which it accesses; rather, FIG. 6 shows a function-based arrangement of the system 
it may form an external, remote component 10', which is c0 ents> nitration shows a three-level compo- 
located in another system part. Whether such movement is nent hicrarch m which a t k comprises actua i 
expedient depends on the respective boundary conditions at applicationS) a center layer corapr ise S application-support 
that time, in particular the complexity and the cosU for data Wi md a lower la cornpr ise S interface control 
communication between the system parts Apart from this, ^ components in the ^ layer form the actual 
the position manager component 10, like all the components applications or serviceS) that fe t0 say app i icati on compo- 
in the system according to the invention, also in turn has a nents ^ AIC^, AK3, ... An initial message reader and a 
remote interface 10a for communication with other services navi ation component are shown by way of exampIe . To 
18a, Wb, and a configuration interface 105. carfy ^ theif ^ ^ application components ak,, 
FIG. 4 shows, once again embedded in its system 3Q ak^ . . . access the center layer of application-supporting 
environment, a presentation manager component 19 with a components UK,, UK,, UK 3) . . . , which may also be 
remote interface 19a for function calling from other appli- referred to as aggregation components, since they appropri- 
cations 20a, 20b and a configuration interface 19b. The ately aggregate raw data, which may come from various 
presentation manager component 19 is responsible for pass- sources in the vehicle and from the network infrastructure 
ing on information relating to the applications 20a, 20b, and 35 external to the vehicle. Examples of such application- 
passes the information on to the user depending on inter- support components are the location manager and presen- 
changeable strategies. These strategies may, for example, tation manager components explained above, as well as the 
include information being provided only via a voice output communication manager component. These application- 
while driving and a visual display being activated only when supporting components UK,, UK^, UK 3 , ... for their part 
stationary. Such strategies allow necessary safety precau- 4Q access tne interface components IK,, IK*, IK 3 , ... in the 
tions to be incorporated in the system so that the vehicle i ower i ayer ^ wmcn represent components that are closely 
occupant or occupants is or are not distracted from their linked to hardware appliance units on the vehicle side, such 
actual task. as tne (serial) port manager explained above, a CAN man- 
Apart from appropriate interfaces, via respective interface a ger component, and a display manager component, 
manager components 21, 22 the presentation manager has 45 The component loader KL is assigned to all the 
access to user interface components in the vehicle, such as components, and communication with external appliances, 
"text-to-speecb" and "speech-to-text" appliances 23, visual sucn as a v i sua ] display 24, an audio interface 27, modems 
displays 24 and "touchscreen" and "pointing" appliances to 28, a GPS receiver 29 and a DVD 30 takes place via the 
carry out its task. The presentation manager component 19 JVM/operating system layer 15. In this way, the system 
interacts closely with the system configuration management, 50 supports external appliances which can be assigned to the 
since it requires information on the input and output appli- user interface, as well as appliances which the user fits to the 
ances that are present in the vehicle. Furthermore, it is able system for the first time. If there are no interface components 
to suitably resolve concurrent output requests from different for retrofitted external appliances, they can be loaded retro- 
applications, comparable to a "Window Manger". spectively. The said components, which are broken down on 
As stated, the architecture of the distributed vehicle 55 a functional basis into three layers, are jointly assigned a 
information processing and vehicle control system is formed configuration manager component KM using which the 
completely from components. (In order to assist in components can be moved dynamically between the various 
identification, these components are each marked in the system parts of the system. 

figures by a small triangle in the top left-hand corner of their A further application is subsequent loading of 

function block.) 60 components, in particular in the top layer (that is, application 

FIG. 5 shows the basic architecture of the system, com- components). The subsequent loading of such application 

prising a number n of components K,, . . . K„, to which a components may be carried out using the present platform, 

component server KS is assigned and which accesses a and thus overcomes the difficulty that there is often insuf- 

number m of external appliances G, . . . G m via the respective ficient knowledge at the time when the vehicle systems are 

operating system BS. In consequence, from this software 65 configured as to what services will be of interest to the 

point of view, the system comprises a number of compo- customer over the entire life of the vehicle. In particular, this 

nents K 1( . . . K„, which communicate with one another, also relates to services which load software required for their 
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use into the vehicle, from a system part external to the center part of FIG. 7, in which the service support compo- 

vehicle, before the service is carried out. The central element nent 33 is arranged in the infrastructure 32, where it can 

for subsequent loading of components is the component exploit the advantages of the greater computation capacity 

loader KL, which not only allows new components to be a nd the availability of further resources located in the data 

incorporated in the relevant system part, but it also allows 5 network, such as up-to-date traffic data. In this case, the 

the removal of components which are no longer required. vehicle forms a " thin mobile host "- 

Tbe capability to move components dynamically is of ™ c d ^ am j c movement of components, such as the 

interest for vehicle systems, particularly bearing in mind the serv . l f ? u PP° rt «>*P°?«* 33 m this case is now used to 

r , . *• ■!■ . i u * i j t*i_ avoid a long-term restriction to one or the other of these two 

limited computation capacities on the vehicle side. Thus, on , , . , , . , t it _ 

i * • , • » • ti , , . , in solutions and, instead, to be able to move the components 

the one hand, it is desirable to need to reserve only a ]U , , , , r , , A . 4 , r . iL . 

, , ' . . , . . /- backwards and forwards between the system parts, in this 

relatively small computation capacity in the vehicle and for . „ . £ . , J , iL r , 

• i j c il i i*' *u.u. ■ *u * case between the infrastructure 32 and the vehicle 31, 

the main load or the calculations to be borne in the system . , , Al . . iL 

. e . . . ,. , ~ , \ depending on the boundary conditions, throughout the sys- 

mfrastructure external to the vehicle. On the other hand, the , r f, 4 . 4 ' * 

. 4 f . . i . i . j tem life; that is. to move the service support component 33 

communications costs for is coupling the vehicle-side sys- „ . . , . , ^ . 4 iL r . r r , f 

. , , i u u u i * i -Li k optionally into the vehicle 31 or into the infrastructure 32, as 

tem part to the network should be kept as low as possible. 15 . , . iL . A , _ ™ , . . _ ' 

y y , • . . r • j . , is shown in the lower part of FIG. 7. The vehicle 31 then 

However, the communications costs now diner considerably c u ,« « » .. . , . , . 4 . 

. ,. *u « . r» • forms a component-based host into which it is possible 

in some cases, depending on the state or region. Bearing m i i * i j . r iL -r.T 

* j iL 7 ,-. r . • i u j j . . . selectively to load components from the infrastructure 32, 

mind the mobility of vehicles, these boundary conditions , r . • j • * ^ • ^ 

i » • . i* a .u and from which components can be moved into the infra- 
may even change during a journey. If, furthermore, the structure 32 
absolute availability of a communications service is also 20 ^ . ' , , . . „ , 
included in the cost model, then this results in an optimi- ,, 71115 e5sentlal characteristic of the present system w,U be 
zation problem which can be solved considerably better with rthistnled more specifically u^ing the example of a voice 
the capability to remove components dynamically between contro1 a PP llc atlon ln mGS „ * a ,f d ^ J 10 ' 8fl sh ° ws u a 
the system parts than with a rigid structure and the compo- v0,ce contr ° 1 s y stem controller 36, which is equipped with 
nents being distributed 25 a component system, that is to say with a component loader. 

_ * ™ . . , The necessary hardware, that is to say a loudspeaker 37 and 

The configuration manager KM is now used to config- a microphone 38 are accessed via the concur 36. The 
ure a respect.ve moved component into its new environ- fo „ owin com n(s nQ in this tem , A hardware . 
ment and to "inform the already existing components about rekted co nt 39 ^ used to access the microphone 38 
the component which is to be newly added to the relevant and (he louds eaker 37. Aflrst application-supporting corn- 
system part, that is to say to match its configuration to tins. t 40 contajns the vocabulary required for tlle desired 
To this end, the configuraUon manager KM has access via voice control> for £ k in Germln Asecond ap p lication . 
the configuration interfaces to the individual componentsir. rti component 41 forms a speech recognizer and 
the relevant system part. The configuration manager KM synthesizer> which carries out the neC essary speech recog- 
knows which components there are m the system, checks n]Aoa and fa s thesis M application componen t in 
their consistency, and then makes the suitable modified ^ form of ^ messa e reader 42 ^ used to ^^,0] ^ 
configuration accesses to the individual components. application 

FIG. 7 shows the capability for dynamic movement of a Based on ^ voice contro i sys tem part, one possible 

component between a vehicle 31, on the one hand, and a scenario consists of the vocabulary component 40 being 

system infrastructure 32 external to the vehicle, on the other 4Q rcp i ace d by one using a different language in order to match 

hand, using the example of a service support component 33 the systemj and ^ the vehicle, to different countries. A 

and based on three different scenarios which make such different scenario may occur in the case of a rented vehicle 

component movement desirable. In this context, see also the in which the matching to the respective language desired by 

Journal article S. Hild and P. Robinson, "Mobilizing a customer is implemented by allowing the customer to use 

Applications", IEEE Personal Communications, 4, No. 5, 45 a menu to select the vocabulary component with the respec- 

1997, page 26. This is based on an upgraded client/server tive i anguage) after wh i c h the relevant component is then 

model, m which the service support component 33 is also loaded. Once the rented vehicle has been returned, the 

connected, as a server, between a presentation manager subsequently loaded component is then removed again, 

component 34 in the vehicle 31 as the client and a server A morc kx situation rclating tQ component movc . 

component 35 on the infrastructure side, and which, to a 5Q men t for the system part in FIG. Sa is shown in FIG. 86. This 

reduced extent, can carry out certain server functions instead situation rdates {Q ^ componcnis of ^ voi ce control 

of the server component 35 on the infrastructure side. syslem paft ^ possib]e being moved Qut of ^ yehicle 36 

If the communications costs between the vehicle 31 and mt0 system parts external to the vehicle; that is, into the 
the infrastructure 32 are high, the solution illustrated in the overa n sys tem infrastructure 43 that is external to the 
top part of FIG. 7 is chosen, in which the service support S5 vehicle. Specifically, the present system's capability for 
component 33 is positioned in the vehicle 31, so that it can dynamic component movement allows the application corn- 
handle its communication with the presentation manager 34 ponent 42 and the two application-supporting components 
within the vehicle, and a high proportion of the calculations 40 , 41 to be moved into the infrastructure 43, where they can 
are carried out in the vehicle 31, thus keeping the commu- operate more efficiently owing to the greater computer 
nication with the infrastructure 32 minimal, or avoiding it 60 powcr nc interface component 40, which is close to the 
entirely at times. In this case, the vehicle forms a "thick vehicle equipment, remains in the vehicle 36. The data are 
mobile host" which contains a reduced version of the server transmitted via the interface component 40, which remains 
component 35 on the infrastructure side, in the form of the on the vehicle side, and a wireless connection 44 between 
service support component 33. the vehicle 36 and the infrastructure 43 external to the 

If the cost of communication between the vehicle 31 and 65 vehicle. Depending on the existing wireless communication, 

the infrastructure 32 is, on the other hand, comparatively in particular its availability and its costs, it is in this way 

low, it is advantageous to choose the solution shown in the possible to choose an optimum compromise for the distri- 
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bution of the components 39 to 42 of the voice control 50. If another application 52 is interested in such data, it 
system between the vehicle 36 and the infrastructure 43 obtains the relevant data information 54 from the data- 
external to the vehicle. maintenance component 50, provided it has registered with 
Depending on the requirements for vehicle-related tnis component for that purpose. The other application 52 
services, such as telematics services, the present distributed s can generate new data 55 from this and make such data 
vehicle information processing and vehicle control system available to the other components, by writing the data to the 
has a specific basic number of components in vehicles and data-maintenance component 50. If the calendar application 
in the infrastructure, which offer services such as "time", 52 is interested in this new data 55, it can obtain the relevant 
"location/position" or "map matching". These basic services information 56 from the data-maintenance component 50, 
may then be used by a number of other services. Thus, for 10 after which the data replacement cycle can start once again 
example, the position information may be used not only by fr° m me beginning. 

a navigation service but also by a breakdown service, in The advantage of this model is the mutually independent 
order to pass on the present vehicle position to the break- programming of the components and the small amount of 
down assistant. Service providers do not need to repeatedly "shared-space" API. Furthermore, new components can be 
remove such basic parts of the system, but can build on the 15 integrated in the system without any problems, and imme- 
existing basic components. Using the existing component- diately actively contribute to the provision of value-added 
based system architecture, new services can be provided on services. To do this, applications must be written "coopera- 
the basis of existing components in two ways that are tively" that is to say such that they also actually write 
supported by the system architecture, to be precise using an relevant information to the "shared-space" component. Suit- 
interface -based service model, or an event-controlled ser- 20 able mechanisms, such as time monitoring, transaction 
vice model. models, etc., are implemented in the "shared-space" com- 

In the interface-based model, it is assumed that the ponent and suppress the occurrence of oscillating effects 

existing components and their service interfaces (which may between components when new values are alternately being 

in some circumstances be comprehensive) together with all written to the "shared-space" component, 

the necessary methods are known. A new service can then 25 A combined implementation of partially interface -based 

easily be produced by use of the existing functions. This is modeling and partially event-controlled modeling, depend- 

dependent on the necessary knowledge being maintained ing on the respective applications, may be advantageous, 

relating to the fundamental existence of the component and Thus, for example, when processing an engine speed value, 

its precise service scope. which is available all the time at intervals of a few 

FIG. 9 shows a navigation sub -system which is designed 30 milliseconds, an event-controlled model, in which each new 

using such an interface -based model. In this case, a "navi- speed value is written to the "shared-space" component and 

gation service" component 45 accesses the services of other a U potential recipient components are informed of this, 

components, such as a mapping component 46, a routing makes little sense, so that interface -based modeling is to be 

component 47, a wheel rotation-speed detection component 35 preferred for this purpose. 

48, a presentation manager component 49 etc., in order to A platform-independent implementation of the present 
provide the user with their service. When the navigation distributed vehicle information processing and vehicle con- 
service component 45 is being programmed, the interfaces trol system is feasible, as already explained, for example by 
of the components used must be known. choosing the development and implementation environment 

FIG. 10 shows the situation for an event-controlled 40 "Java", since this already directly supports an object- 
model, which is provided by using a "shared-space" com- oriented implementation of components at many points, and 
ponent 50 which represents a server-based data memory that in this case, as has likewise been mentioned above, the 
is used jointly by a number of components that are involved, ChaiServer from Hewlett-Packard, implemented in Java 
to which the components that are involved can write specific may, for example, be used as the component loader. To allow 
values/objects of interest, as is illustrated in FIG. 10 for a 45 access to the system hardware, which is not envisaged as 
calendar application component 51 and a further application standard by Java, additional classes are introduced to the 
component 52. Furthermore, the components that are system, which are likewise monitored via the system con- 
involved can be registered with this "shared-space" compo- figuration management and are loaded into the vehicle only 
nent 50, which thus acts as a data-maintenance component when required. The removal of a component, in order to 
in order to be informed when a new value/object which is 50 release the relevant resource once again, is likewise sup- 
relevant for it occurs, referred to as a so-called "event- ported by the ChaiServer in the scope of the dynamic 
triggered notification". component movement process. 

Approaches of this type move the knowledge problem The Java implementation results in a high level of plat- 
relating to the existence of components (mentioned above) form independence. Components may be stored in a corn- 
to a higher level, since the communication between com- 55 ponent database, in the infrastructure external to the vehicle, 
ponents always takes place via the "shared -space" compo- and may be loaded into the appropriate systems as required, 
nent 50, which can be provided using a very small API and The components are preferably modeled and implemented 
is known to each component. The components need agree using object-based viewpoints, and are in this case similar to 
only on the contents, which are written to the "shared-space" the Java "Servlets", which are used to increase the func- 
component 50. Such approaches are well known, for 60 lionality of the server in a simple way, see for general 
example by the terms "Linda Space", see Internet page computer processing, the publication "Servlets" from Sun 
"http://www.cs.yale.edu/HTML/YALE/CS/Linda/ Microsystems, Internet page "http://java.sun.com/products/ 
linda.html" and "Java Spaces", Sun Microsystems, Internet javaserver/servlets". Communication between the compo- 
page http://java.sun.com/products/javaspaces/specs", in nents is based on Java-RML 

general computer processing. 6S Methods for components which run in the context of the 

In the example in FIG. 10, the calendar application 51 ChaiServer are called up by means of HTTP. See J. Morgan, 

supplies new entries 53 to the data-maintenance component "The HEHAW Invocation Model," Broadband Information 
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Systems, Hewlett-Packard, Palo Alto, 1997. The use of 
HTTP has the advantage that it is virtually universally 
supported and "firewalls" can also be transferred. The 
desired position transparency is achieved by the addressing 
and call syntax mentioned above using a "uniform resource s 
locator" (URL). 

FIG. 11 shows an application relating to this with an 
example of a component 57, which is implemented on a 
vehicle machine 58. The component 57 provides a "Foo" 
method, which is called up using a string argument. The 10 
result of the method may be an HTML document. The HTTP 
call syntax for a call 59 by another component 60 then 
contains the address of the vehicle machine 58, the desig- 
nation of the example of a component 57, and the details of 
the "Foo" method with "html" characterization. 55 

The above description of an advantageous exemplary 
embodiment and possible modifications to it makes it clear 
that the distributed vehicle information processing and 
vehicle control system according to the invention provides a 
flexible and dynamically adaptable environment for vehicle- 20 
related service applications. The object-based modeling and 
capability to combine the components easily by means of 
their standard interfaces allow new services to be set up 
quickly and easily. The capability to move components 
between the vehicle and the infrastructure external to the 25 
vehicle throughout the system life allows the system to be 
optimally matched to the dynamically changing boundary 
conditions in the infrastructure. 

The foregoing disclosure has been set forth merely to 3Q 
illustrate the invention and is not intended to be limiting. 
Since modifications of the disclosed embodiments incorpo- 
rating the spirit and substance of the invention may occur to 
persons skilled in the art, the invention should be construed 
to include everything within the scope of the appended 35 
claims and equivalents thereof. 

What is claimed is: 

1. A distributed vehicle information processing and 
vehicle control system comprising: 

a first system part situated on board the vehicle and having 40 
hardware and software to perform at least a first 
vehicle-related information processing function; 

at least one second system part situated at a location 
physically separate from said first system part, and 
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having hardware and software to perform at least a 
second vehicle-related information processing func- 
tion; and 

a data transmission network via which said first system 
part and said at least one second system part commu- 
nicate with one another, wherein: 
each of the first system part and the at least one second 
system part includes different software components 
which perform differing functionality, and which 
communicate and cooperate with one another to 
carry out different vehicle related applications using 
shared functionality of said components; 
each of said components has a function-calling 
interface, via which a function carried out by the 
component is accessible by other components in the 
same system part or in another system part, and a 
configuration interface, via which a configuration of 
the component is definable and variable; 
a configuration manager component is provided for 
configuring each component via its respective con- 
figuration interface, depending on what other com- 
ponents are present in the system, and depending on 
a location or relocation of components as between 
said first system part and said at least one second 
system part; and 
said system includes means for addition of components 
to or removal of components from, or movement of 
one or more components dynamically between, said 
first system part and said at least one second system 
part. 

2. The distributed system according to claim 1, further 
comprising a component loader which is associated with the 
components of a respective system part. 

3. The distributed system according to claim 1, wherein 
the components in a respective system part are grouped 
hierarchically on a function-specific basis in an application 
component layer, an interface component layer, and an 
intermediate aggregation component layer. 

4. The distributed system according to claim 1, wherein 
respective application components communicate one of 
directly, using an interface-based model, and via a data- 
maintenance component, using an event-controlled model. 
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